<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<TITLE>RFC 1459</TITLE>
<META NAME="author" CONTENT="Content: J. Oikarinen, D.Reed, HTML: Tatu J. Lund">
<META NAME="keywords" CONTENT="rfc1459 irc internet relay chat protocol">
<META NAME="description" CONTENT="HTML version of internet relay chat protocol (IRC) specification (RFC1459). Material for TUUG club seminary.">
<LINK REV="made" HREF="mailto:f@tuug.org">
</HEAD>

<BODY BGCOLOR="#FFFFE8" TEXT="#7A0818">

<MAP NAME="nav_map">
<AREA SHAPE=RECT HREF="/irchelp/" COORDS="1,1,70,38" ALT="">
<AREA SHAPE=RECT HREF="/irchelp/search_engine.cgi" COORDS="72,1,141,38" ALT="">
<AREA SHAPE=RECT HREF="/irchelp/help.html" COORDS="143,1,212,38" ALT="">
<AREA SHAPE=RECT HREF="/irchelp/mail.cgi" COORDS="214,1,283,38" ALT="">
</MAP>

<CENTER>
<TABLE WIDTH=80%>
<TR>
<TD>

<CENTER>
<FONT SIZE=1>HTML layout by Tatu J. Lund Apr 1997</FONT>
</CENTER>

<TABLE WIDTH=100%>
<TR>
<TD ALIGN=LEFT>
Network Working Group<BR>     
Request for Comments: 1459
</TD>
<TD ALIGN=RIGHT>
J. Oikarinen<BR>
D. Reed<BR>
May 1993
</TD>
</TR>
</TABLE>
<HR NOSHADE>

<A NAME="c8"></A>
<H1>8. Current implementations</H1>

   <P>The only current implementation of this protocol is the IRC server,
   version 2.8. Earlier versions may implement some or all of the
   commands described by this document with NOTICE messages replacing
   many of the numeric replies.  Unfortunately, due to backward
   compatibility requirements, the implementation of some parts of this
   document varies with what is laid out.  On notable difference is:</P>

        <UL>
        <LI>recognition that any LF or CR anywhere in a message marks the
          end of that message (instead of requiring CR-LF);</LI>
        </UL>

   <P>The rest of this section deals with issues that are mostly of
   importance to those who wish to implement a server but some parts
   also apply directly to clients as well.</P>

<A NAME="c8_1"></A>
<H2>8.1 Network protocol: TCP - why it is best used here.</H2>

   <P>IRC has been implemented on top of TCP since TCP supplies a reliable
   network protocol which is well suited to this scale of conferencing.
   The use of multicast IP is an alternative, but it is not widely
   available or supported at the present time.</P>

<A NAME="c8_1_1"></A>
<H3>8.1.1 Support of Unix sockets</H3>

   <P>Given that Unix domain sockets allow listen/connect operations, the
   current implementation can be configured to listen and accept both
   client and server connections on a Unix domain socket.  These are
   recognized as sockets where the hostname starts with a '/'.</P>

   <P>When providing any information about the connections on a Unix domain
   socket, the server is required to supplant the actual hostname in
   place of the pathname unless the actual socket name is being asked
   for.</P>

<A NAME="c8_2"></A>
<H2>8.2 Command Parsing</H2>

   <P>To provide useful 'non-buffered' network IO for clients and servers,
   each connection is given its own private 'input buffer' in which the
   results of the most recent read and parsing are kept.  A buffer size
   of 512 bytes is used so as to hold 1 full message, although, this
   will usually hold several commands.  The private buffer is parsed
   after every read operation for valid messages.  When dealing with
   multiple messages from one client in the buffer, care should be taken
   in case one happens to cause the client to be 'removed'.</P>

<A NAME="c8_3"></A>
<H2>8.3 Message delivery</H2>

   <P>It is common to find network links saturated or hosts to which you
   are sending data unable to send data.  Although Unix typically
   handles this through the TCP window and internal buffers, the server
   often has large amounts of data to send (especially when a new
   server-server link forms) and the small buffers provided in the
   kernel are not enough for the outgoing queue.  To alleviate this
   problem, a "send queue" is used as a FIFO queue for data to be sent.
   A typical "send queue" may grow to 200 Kbytes on a large IRC network
   with a slow network connection when a new server connects.</P>

   <P>When polling its connections, a server will first read and parse all
   incoming data, queuing any data to be sent out. When all available
   input is processed, the queued data is sent. This reduces the number
   of write() system calls and helps TCP make bigger packets.</P>

<A NAME="c8_4"></A>
<H2>8.4 Connection 'Liveness'</H2>

   <P>To detect when a connection has died or become unresponsive, the
   server must ping each of its connections that it doesn't get a
   response from in a given amount of time.</P>

   <P>If a connection doesn't respond in time, its connection is closed
   using the appropriate procedures.  A connection is also dropped if
   its sendq grows beyond the maximum allowed, because it is better to
   close a slow connection than have a server process block.</P>

<A NAME="c8_5"></A>
<H2>8.5 Establishing a server to client connection</H2>

   <P>Upon connecting to an IRC server, a client is sent the MOTD (if
   present) as well as the current user/server count (as per the LUSER
   command).  The server is also required to give an unambiguous message
   to the client which states its name and version as well as any other
   introductory messages which may be deemed appropriate.</P>

   <P>After dealing with this, the server must then send out the new user's
   nickname and other information as supplied by itself (USER command)
   and as the server could discover (from DNS/authentication servers).
   The server must send this information out with NICK first followed by
   USER.</P>

<A NAME="c8_6"></A>
<H2>8.6 Establishing a server-server connection.</H2>

   <P>The process of establishing of a server-to-server connection is
   fraught with danger since there are many possible areas where
   problems can occur - the least of which are race conditions.</P>

   <P>After a server has received a connection following by a PASS/SERVER
   pair which were recognised as being valid, the server should then
   reply with its own PASS/SERVER information for that connection as
   well as all of the other state information it knows about as
   described below.</P>

   <P>When the initiating server receives a PASS/SERVER pair, it too then
   checks that the server responding is authenticated properly before
   accepting the connection to be that server.</P>

<A NAME="c8_6_1"></A>
<H3>8.6.1 Server exchange of state information when connecting</H3>

   <P>The order of state information being exchanged between servers is
   essential.  The required order is as follows:</P>

        <UL>
        <LI>all known other servers;</LI>

        <LI>all known user information;</LI>

        <LI>all known channel information.</LI>
        </UL>

   <P>Information regarding servers is sent via extra SERVER messages, user
   information with NICK/USER/MODE/JOIN messages and channels with MODE
   messages.</P>

   <P>NOTE: channel topics are *NOT* exchanged here because the TOPIC
   command overwrites any old topic information, so at best, the two
   sides of the connection would exchange topics.</P>

   <P>By passing the state information about servers first, any collisions
   with servers that already exist occur before nickname collisions due
   to a second server introducing a particular nickname.  Due to the IRC
   network only being able to exist as an acyclic graph, it may be
   possible that the network has already reconnected in another
   location, the place where the collision occurs indicating where the
   net needs to split.</P>

<A NAME="c8_7"></A>
<H2>8.7 Terminating server-client connections</H2>

   <P>When a client connection closes, a QUIT message is generated on
   behalf of the client by the server to which the client connected.  No
   other message is to be generated or used.</P>

<A NAME="c8_8"></A>
<H2>8.8 Terminating server-server connections</H2>

   <P>If a server-server connection is closed, either via a remotely
   generated SQUIT or 'natural' causes, the rest of the connected IRC
   network must have its information updated with by the server which
   detected the closure.  The server then sends a list of SQUITs (one
   for each server behind that connection) and a list of QUITs (again,
   one for each client behind that connection).</P>

<A NAME="c8_9"></A>
<H2>8.9 Tracking nickname changes</H2>

   <P>All IRC servers are required to keep a history of recent nickname
   changes.  This is required to allow the server to have a chance of
   keeping in touch of things when nick-change race conditions occur
   with commands which manipulate them.  Commands which must trace nick
   changes are:</P>
        
        <UL>
        <LI>KILL (the nick being killed)</LI>

        <LI>MODE (+/- o,v)</LI>

        <LI>KICK (the nick being kicked)</LI>
        </UL>

   <P>No other commands are to have nick changes checked for.</P>

   <P>In the above cases, the server is required to first check for the
   existence of the nickname, then check its history to see who that
   nick currently belongs to (if anyone!).  This reduces the chances of
   race conditions but they can still occur with the server ending up
   affecting the wrong client.  When performing a change trace for an
   above command it is recommended that a time range be given and
   entries which are too old ignored.</P>

   <P>For a reasonable history, a server should be able to keep previous
   nickname for every client it knows about if they all decided to
   change.  This size is limited by other factors (such as memory, etc).</P>

<A NAME="c8_10"></A>
<H2>8.10 Flood control of clients</H2>

   <P>With a large network of interconnected IRC servers, it is quite easy
   for any single client attached to the network to supply a continuous
   stream of messages that result in not only flooding the network, but
   also degrading the level of service provided to others.  Rather than
   require every 'victim' to be provide their own protection, flood
   protection was written into the server and is applied to all clients
   except services.  The current algorithm is as follows:</P>
        
        <UL>
        <LI>check to see if client's `message timer' is less than
          current time (set to be equal if it is);</LI>

        <LI>read any data present from the client;</LI>

        <LI>while the timer is less than ten seconds ahead of the current
          time, parse any present messages and penalize the client by
          2 seconds for each message;</LI>
        </UL>

   <P>which in essence means that the client may send 1 message every 2
   seconds without being adversely affected.</P>

<A NAME="c8_11"></A>
<H2>8.11 Non-blocking lookups</H2>

   <P>In a real-time environment, it is essential that a server process do
   as little waiting as possible so that all the clients are serviced
   fairly.  Obviously this requires non-blocking IO on all network
   read/write operations.  For normal server connections, this was not
   difficult, but there are other support operations that may cause the
   server to block (such as disk reads).  Where possible, such activity
   should be performed with a short timeout.</P>

<A NAME="c8_11_1"></A>
<H3>8.11.1 Hostname (DNS) lookups</H3>

   <P>Using the standard resolver libraries from Berkeley and others has
   meant large delays in some cases where replies have timed out.  To
   avoid this, a separate set of DNS routines were written which were
   setup for non-blocking IO operations and then polled from within the
   main server IO loop.</P>

<A NAME="c8_11_2"></A>
<H3>8.11.2 Username (Ident) lookups</H3>

   <P>Although there are numerous ident libraries for use and inclusion
   into other programs, these caused problems since they operated in a
   synchronous manner and resulted in frequent delays.  Again the
   solution was to write a set of routines which would cooperate with
   the rest of the server and work using non-blocking IO.</P>

<A NAME="c8_12"></A>
<H2>8.12 Configuration File</H2>

   <P>To provide a flexible way of setting up and running the server, it is
   recommended that a configuration file be used which contains
   instructions to the server on the following:</P>

        <UL>
        <LI>which hosts to accept client connections from;</LI>

        <LI>which hosts to allow to connect as servers;</LI>

        <LI>which hosts to connect to (both actively and
          passively);</LI>

        <LI>information about where the server is (university,
          city/state, company are examples of this);</LI>

        <LI>who is responsible for the server and an email address
          at which they can be contacted;</LI>

        <LI>hostnames and passwords for clients which wish to be given
          access to restricted operator commands.</LI>
        </UL>

   <P>In specifying hostnames, both domain names and use of the 'dot'
   notation (127.0.0.1) should both be accepted.  It must be possible to
   specify the password to be used/accepted for all outgoing and
   incoming connections (although the only outgoing connections are
   those to other servers).</P>

   <P>The above list is the minimum requirement for any server which wishes
   to make a connection with another server.  Other items which may be
   of use are:</P>
        
        <UL>
        <LI>specifying which servers other server may introduce;</LI>

        <LI>how deep a server branch is allowed to become;</LI>

        <LI>hours during which clients may connect.</LI>
        </UL>

<A NAME="c8_12_1"></A>
<H3>8.12.1 Allowing clients to connect</H3>

   <P>A server should use some sort of 'access control list' (either in the
   configuration file or elsewhere) that is read at startup and used to
   decide what hosts clients may use to connect to it.</P>

   <P>Both 'deny' and 'allow' should be implemented to provide the required
   flexibility for host access control.</P>

<A NAME="c8_12_2"></A>
<H3>8.12.2 Operators</H3>

   <P>The granting of operator privileges to a disruptive person can have
   dire consequences for the well-being of the IRC net in general due to
   the powers given to them.  Thus, the acquisition of such powers
   should not be very easy.  The current setup requires two 'passwords'
   to be used although one of them is usually easy guessed.  Storage of
   oper passwords in configuration files is preferable to hard coding
   them in and should be stored in a crypted format (ie using crypt(3)
   from Unix) to prevent easy theft.</P>

<A NAME="c8_12_3"></A>
<H3>8.12.3 Allowing servers to connect</H3>

   <P>The interconnection of server is not a trivial matter: a bad
   connection can have a large impact on the usefulness of IRC.  Thus,
   each server should have a list of servers to which it may connect and
   which servers may connect to it.  Under no circumstances should a
   server allow an arbitrary host to connect as a server.  In addition
   to which servers may and may not connect, the configuration file
   should also store the password and other characteristics of that
   link.</P>

<A NAME="c8_12_4"></A>
<H3>8.12.4 Administrivia</H3>

   <P>To provide accurate and valid replies to the ADMIN command (see
   section <A HREF="chapter4.html#c4_3_7">4.3.7</A>), the server should find the relevant details in the
   configuration.</P>

<A NAME="c8_13"></A>
<H2>8.13 Channel membership</H2>

   <P>The current server allows any registered local user to join upto 10
   different channels.  There is no limit imposed on non-local users so
   that the server remains (reasonably) consistant with all others on a
   channel membership basis</P>

<HR WIDTH=50% NOSHADE>

<TABLE WIDTH=100% BORDER=0>
<TR>
<TD ALIGN=LEFT><A HREF="chapter7.html"><FONT SIZE=+3>&lt;</FONT></A></TD>
<TD ALIGN=CENTER><A HREF="rfc.html"><FONT SIZE=+3>^</FONT></A></TD>
<TD ALIGN=RIGHT><A HREF="chapter9.html"><FONT SIZE=+3>&gt;</FONT></A></TD>
</TR>
</TABLE>

</TD>
</TR>
</TABLE>
</CENTER>

<HR>
<CENTER>
<!-- navigation bar -->
<IMG SRC="/irchelp/Pix/ihnavbar.gif" WIDTH=285 HEIGHT=40 BORDER=0 USEMAP="#nav_map"
	ALT="-navigational bar-">
<BR><SMALL>
[ <A HREF="/irchelp/">go back</A>
| <a href="/irchelp/search_engine.cgi">search</A>
| <A HREF="/irchelp/help.html">help</A>
| <A HREF="/irchelp/mail.cgi">send email</A> ]
</SMALL>
<P>
</CENTER>

<CENTER><SMALL>
<A HREF="/irchelp/credit.html">all pages &copy; IRCHELP.ORG or original authors</A><BR>
</SMALL></CENTER>

</BODY>
</HTML>
